[AArch64] Skip test aarch64-init-cpu-features if FMV runtime unavailable. #269

IamYJLee · 2025-07-21T07:05:36Z

ERROR CONTEXT

Before this patch, LNT test runs on AArch64 platforms (e.g., macOS arm64) could fail with missing symbol errors:

--- Tested: 140 tests --
FAIL: SingleSource/Benchmarks/Misc/aarch64-init-cpu-features.compile_time (1 of 140)
FAIL: SingleSource/Benchmarks/Misc/aarch64-init-cpu-features.execution_time (29 of 140)
Processing Times

Undefined symbols for architecture arm64:
  "_RUNTIME_INIT", referenced from:
      _main in aarch64-init-cpu-features.llvm.o
ld: symbol(s) not found for architecture arm64

Patch Description

Selects __init_cpu_features_resolver for Darwin, and __init_cpu_features for Linux.
Attempts to compile a dummy program to detect availability of the symbol via TARGET_LLVMGCC.
Adds corresponding macro (HAS_DARWIN_FMV or HAS_LINUX_FMV) if detection succeeds.
Skips test if the symbol is undefined.

This change fixes build errors when running LNT tests on AArch64 using Make rather than CMake.
This patch reflects the changes from llvm/llvm-test-suite@d24d5dcd.

Co-authored-by: Lee Young Joon dog3hk.dev@gmail.com
Co-authored-by: Alexandros Lamprineas alexandros.lamprineas@arm.com
Co-authored-by: Momchil Velikov momchil.velikov@arm.com

Add conditional CFLAGS definitions for AArch64 targets to support FMV-related behavior on Darwin and Linux platforms. - Adds -DHAS_DARWIN_FMV when ARCH=AArch64 and TARGET_OS=Darwin - Adds -DHAS_LINUX_FMV when ARCH=AArch64 and TARGET_OS=Linux This change fixes build errors when running LNT tests on AArch64 systems with platform-specific FMV handling.

labrinea · 2025-07-21T09:23:49Z

I am a bit puzzled with the equivalent cmake code

file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/CheckHasAArch64FMV.h "void __init_cpu_features_resolver(void);")
check_symbol_exists(__init_cpu_features_resolver ${CMAKE_CURRENT_BINARY_DIR}/CheckHasAArch64FMV.h HAS_AARCH64_FMV)

The way I read it HAS_AARCH64_FMV is always true? Am I mistaken, do we need it here too perhaps? cc @jroelofs

IamYJLee · 2025-07-21T14:16:04Z

@labrinea Thank you for your comment.

I've confirmed how check_symbol_exists functions and understand that HAS_AARCH64_FMV is not always true. In my environment, when I configure the project using CMakeLists.txt, HAS_AARCH64_FMV is set to False.

However, when I run LNT with a Makefile that includes my modifications, the build and execution complete without any issues.

In other words, even though check_symbol_exists confirms that the __init_cpu_features_resolver symbol is missing, there are no problems compiling and running aarch64-init-cpu-features.c.

- Adds a pre-build check in the Makefile for the __init_cpu_features_resolver, __init_cpu_features symbol. - The result is used to define CHECK_FMV (HAS_DARWIN_FMV, HAS_LINUX_FMV), which conditionally compiles the platform-specific code in aarch64-init-cpu-features.c

IamYJLee · 2025-07-23T05:42:31Z

@labrinea
I'm using the following command and encountering an Undefined Symbol error.

./mysandbox/bin/lnt runtest nt --sandbox ./result --cc ./llvm-project/build/bin/clang --test-suite ./llvm-test-suite -j 16 --only-test SingleSource/Benchmarks/Misc --isysroot `xcrun --show-sdk-path`

To match the CMakeLists.txt configuration and resolve this, I've made the following changes:

I added an #if defined() directive to aarch64-init-cpu-features.c to prevent the problematic code from being compiled when HAS_***_FW is False. (My initial attempt to use PROGRAM_TO_SKIP to exclude the file did not work.)

To replicate the logic from the CMakeLists.txt (below code), I added a step that generates and compiles a temporary header file. The result of this check is stored in the CHECK_FMV variable.

llvm-test-suite/SingleSource/Benchmarks/Misc/CMakeLists.txt

Lines 39 to 40 in 299a0b3

    
           file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/CheckHasAArch64FMV.h "void __init_cpu_features_resolver(void);") 
        
           check_symbol_exists(__init_cpu_features_resolver ${CMAKE_CURRENT_BINARY_DIR}/CheckHasAArch64FMV.h HAS_AARCH64_FMV)

Testing

In my local environment, the check for the __init_cpu_features* symbol always results in 'no'. I've confirmed my changes work as intended by manually setting the CHECK_FMV variable to both 'yes' and 'no'.

Could you please test these changes in an environment where the __init_cpu_features* symbol check would result in 'yes'?

labrinea · 2025-07-24T17:03:53Z

I have raised #270 to address the problem. I am not sure who to ask for review. I tested it and works on a system that has the __init_cpu_features symbol. My doubt is whether $(TARGET_LLVMGCC) is the right compiler. Also whether --rtlib=compiler-rt should be inferred from the existing CFLAGS

IamYJLee · 2025-07-25T00:51:15Z

Hi @labrinea ,

Thank you for the review and for following up with a fix.

I noticed that instead of merging PR #269, you made a separate commit to address the issue.
Would you mind sharing the reasoning behind that? I’d really like to understand the process and expectations better.

If there are specific improvements or changes needed, I’d sincerely appreciate your guidance so that I can apply them myself.
Whenever possible, I’d prefer to see the contribution through to completion on my end — with your feedback and support. I find this helps me improve and feel more ownership of the patch.

Thanks again for your time and help!

labrinea · 2025-07-25T08:18:13Z

Hi @IamYJLee. Apologies for not guiding you how to improve this PR instead. Since I spent the time investing this issue from my end I thought it's easier to raise a new PR with my changes. Allow me to explain why this patch doesn't work.

When overriding the compiler with --cc on the lnt command, it sets CC=None and Target_LLVMGCC=/path/to/compiler, so the shell compile command had no effect
Assuming the compiler was correctly set, the program you are trying to compile doesn't not attempt to find the definition of the symbol, so it always succeeds. Therefore I added an assignment to a function pointer. The compiler needs to be able to resolve this. If not you'll get error in which case the script returns something else than the symbol name.
When not intending to run a test ifdef-ing out the source is a bad practice. Instead we want to use the Makefile variable PROGRAMS_TO_SKIP

Feel free to adjust this PR accordingly and credit @momchil-velikov for helping me on this on the commit message. There are still two issues with my patch that need to be addressed, so we need someone to review these first.

IamYJLee · 2025-07-25T08:41:27Z

@labrinea
Thank you very much for your detailed explanation and for taking the time to investigate and address the issue.

I completely understand your rationale for submitting a new PR, and I appreciate the clarity you've provided regarding the behavior of --cc, the importance of the function pointer assignment for symbol detection, and the recommendation to use PROGRAMS_TO_SKIP over conditional compilation.

With your permission, I would like to continue the work from here and revise the patch to address the remaining issues you mentioned. I will ensure that appropriate credit is given to you in the commit message for your valuable contributions.

Please let me know if you have any objections. Otherwise, I’ll proceed with the necessary updates.

This reverts commit ac0c956.

@momchil-velikov

…able - Selects __init_cpu_features_resolver for Darwin, and __init_cpu_features for Linux. - Attempts to compile a dummy program to detect availability of the symbol via TARGET_LLVMGCC. - Adds corresponding macro (HAS_DARWIN_FMV or HAS_LINUX_FMV) if detection succeeds. - Skips test if the symbol is undefined. Credit to @momchil-velikov and @labrinea for their valuable input and support during review.

SingleSource/Benchmarks/Misc/Makefile

IamYJLee · 2025-07-25T14:04:31Z

@jroelofs @labrinea @momchil-velikov Could you please take a look? Thanks!

labrinea

As I said earlier I am not sure if TARGET_LLVMGCC is the right compiler and whether --rtlib=compiler-rt should be inherited from some CFLAGS variable. I tested this patch and it worked in my environment.

SingleSource/Benchmarks/Misc/Makefile

IamYJLee · 2025-07-25T14:33:15Z

As I said earlier I am not sure if TARGET_LLVMGCC is the right compiler and whether --rtlib=compiler-rt should be inherited from some CFLAGS variable. I tested this patch and it worked in my environment.

The logs for check_symbol_exists indicate that the symbol detection is being carried out using the system’s default compiler rather than the clang compiler we aim to test.
This raises the possibility that CC might be the more appropriate variable to use instead of TARGET_LLVMGCC.
If possible, could you take a look at how check_symbol_exists behaves in your environment?

labrinea · 2025-07-25T16:00:24Z

I am afraid I will only be able to look into this further, after I am back from vacation in two weeks time.

IamYJLee · 2025-08-06T04:02:25Z

@labrinea
PING: Would it be okay to merge this PR first and handle any additional changes in a follow-up?
Please let me know if there’s anything that needs to be addressed before merging.

IamYJLee · 2025-08-07T00:55:26Z

@labrinea I’d appreciate it if you could merge this 🙂.

labrinea · 2025-08-07T05:58:49Z

Do you not have commit access?

IamYJLee · 2025-08-07T06:20:03Z

Yes, I don't have permission for the merge.
I am not LLVM committer yet. (https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access)

labrinea · 2025-08-07T10:38:30Z

Alright I'll merge this on your behalf with some adjustments to the title and description, if that's ok.

IamYJLee · 2025-08-07T10:59:07Z

Sounds good to me. Thank you for handling the merge and updating the title/description!

labrinea · 2025-08-07T11:03:05Z

I need your email address to mention you. I've copied the name from your github account. Lemme know if I spelled it right.

IamYJLee · 2025-08-07T11:15:54Z

Thanks! I’ve added my email address. And yes, you spelled my name correctly.

davemgreen requested a review from labrinea July 21, 2025 07:42

IamYJLee and others added 3 commits July 25, 2025 22:22

Merge branch 'llvm:main' into fix/aarch64-fmv-flags

0629915

Revert "[FMV][AArch64] Fix Undefined Symbol error in LNT Makefile build"

65b1785

This reverts commit ac0c956.

IamYJLee changed the title ~~[FMV][AArch64] Fix missing FMV defines for AArch64 in LNT Makefile~~ [FMV][AArch64] Set HAS_*_FMV macro and skip test if symbol is unavailable Jul 25, 2025

IamYJLee commented Jul 25, 2025

View reviewed changes

SingleSource/Benchmarks/Misc/Makefile Show resolved Hide resolved

labrinea approved these changes Jul 25, 2025

View reviewed changes

IamYJLee commented Jul 25, 2025

View reviewed changes

SingleSource/Benchmarks/Misc/Makefile Show resolved Hide resolved

labrinea changed the title ~~[FMV][AArch64] Set HAS_*_FMV macro and skip test if symbol is unavailable~~ [AArch64] Skip test aarch64-init-cpu-features if FMV runtime unavailable. Aug 7, 2025

labrinea merged commit 69f057c into llvm:main Aug 7, 2025
1 check passed

[AArch64] Skip test aarch64-init-cpu-features if FMV runtime unavailable. #269

[AArch64] Skip test aarch64-init-cpu-features if FMV runtime unavailable. #269

Conversation

IamYJLee commented Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ERROR CONTEXT

Patch Description

Uh oh!

labrinea commented Jul 21, 2025

Uh oh!

IamYJLee commented Jul 21, 2025

Uh oh!

IamYJLee commented Jul 23, 2025

Testing

Uh oh!

labrinea commented Jul 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

IamYJLee commented Jul 25, 2025

Uh oh!

labrinea commented Jul 25, 2025

Uh oh!

IamYJLee commented Jul 25, 2025

Uh oh!

Uh oh!

IamYJLee commented Jul 25, 2025

Uh oh!

labrinea left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

IamYJLee commented Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

labrinea commented Jul 25, 2025

Uh oh!

IamYJLee commented Aug 6, 2025

Uh oh!

IamYJLee commented Aug 7, 2025

Uh oh!

labrinea commented Aug 7, 2025

Uh oh!

IamYJLee commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

labrinea commented Aug 7, 2025

Uh oh!

IamYJLee commented Aug 7, 2025

Uh oh!

labrinea commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

IamYJLee commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

IamYJLee commented Jul 21, 2025 •

edited

Loading

labrinea commented Jul 24, 2025 •

edited

Loading

IamYJLee commented Jul 25, 2025 •

edited

Loading

IamYJLee commented Aug 7, 2025 •

edited

Loading

labrinea commented Aug 7, 2025 •

edited

Loading

IamYJLee commented Aug 7, 2025 •

edited

Loading